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Background 



NAND Flash is used pervasively in 
mobile and embedded devices 

Mobile phones retain: 
-What they said, 
-Who they said it to, 

- Were they said it, 

- What they searched for (what concerns them) 

- Where they travelled 

- When they charged 
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Significant challenges to establishing 
reliable evidence 

• Getting the data out intact 

- Device and OS diversity 

• Interpreting the data into usable evidence 

- Device and OS diversity 

• Absence of scientific rigour from tool vendors 

- Transparency & independent reproducibility missing to 
date 
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The Android landscape isn't 
homogenised 

Bootloader: Redboot, HTC HBoot, Samsung 

Filesystem: YAFFS2, Samsung RFS, EXT4 

FTL: Integrated, MTD, Samsung XSR 

Memory device: Raw NAND flash (xN footprint), 
eMMC... 
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Theory of operation 



An Android Storage Architecture 





Linux Kernel 



















































Flash 
Controller 




MMCCard 
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Flash memory is designed to store 
metadata in addition to each block 



4, D96 blocks for ; 6Gb 



:-a - Mks f W 4&j [ 



DDP 






1 Stock = 64 Pages 
^ (126K + 4K)Wort 



1 Page = (2K + 64}Wotd 

1 Block = (2K + 64)Word x 64 Pages 

= (128K + 4K) Words 
1 Device = (2K + 64)Woiti x 64Pages x 2,D48 Blocks 
= 4,224 Mbfts for 4Gb 
" 16 bit 1 Device = (2K * 64)Word x 64Pages x 4.D96 Blocks 
= 8,446 hftHts for 8Gb DDP 



EMZMP^e Register^ 

2K Wairfs 64 Words 



WOO- I/O IS 



KA100O015E-BJTT 



datasheet 



MCP Memory 



Source: Samsung KA100O015E-BJT rev 1.0 Datasheet 
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The metadata and data may be 
arranged differently in a page 



Adjacent Data and Spare Areas 




Data area 1 Spare area 1 Data area 2 Spare area 2 Data area 3 Spare area 3 Data area 4 Spare area 4 
(51 2 bytes) (16 bytes) (512 bytes) (16 bytes} (512 bytes} (16 bytes) (51 2 bytes) (15 bytes) 



Separate Data and Spare Areas 




Source: Micron TN-29-19 Flash 101 



Pages cannot be individually erased 




Erase block = 64 pages 
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Pages must be written serially to an 
Erase Block 
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Pages can only be written a fixed 
number of times 



Levelling 







Linux Kernel 

























































Flash 
Controller 




MMCCard 
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Bit errors are anticipated 






Linux Kernel 













































Error 
Correction 



Flash 
Controller 




MMCCard 
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MMC Integrates flash controller and 

NAND 






Linux Kernel 














































MMC Card 



Flash 
Translation 
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YAFFS2 stores metadata in the spare 



User Data 
(2048 bytes) 



EEC 

(Handled by MTD 

or Flash Controller) 
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YAFFS2 Basics: Simple file write 




Object Header 

ChunklD = 
File Name = "a" 
Sequence = 0x1001 
Size = 



Data block 1 

ChunklD = l 
Address = 0x0 
Sequence = 0x1001 



Data block 2 

ChunklD = 2 
Address = 2048 
Sequence = 0x1001 



Object Header 



ChunklD = 



File Name = "a" 



Sequence = 0x1001 



Size = 4096 
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Getting the data out 
Acquisition 
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Acquisition principles 

Completeness 
Accuracy 
Repeatability 
Integrity 
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Acquisition methods 

Logical: file copy over android debug bridge 

Pseudo physical: get root, dump NAND block 
devices 

Bootloader 

Physical 1: JTAG access to flash 

Physical 2: Chip off 
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Logical 

Enable ADB on phone 
Connect and recursive copy 



Limited access to files 

No prior versions 

We are trusting the kernel 
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Bootloader approaches 

• Disable bootloader security 

• RAM load custom boot image 

• Dump using "Live" Ramdisk 

• - Wipes most (not all) devices 

• - Limited coverage 

• - Maintenance of "live" ramdisks 



See: Cannon (2012) Into the Driod, Blackhat 

See: Vidas (2011) Toward a general collection methodology for Android devices, DFRWS 
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Pseudo-physical 



• Requires unlocked phone/pin 

• Requires root access to device 

• Range of exploits to do this 

• - Exploit validation 

• - Perception management 

• Dump MTD devices with nanddump 

• - MTD is not accurate 

• - We still don't have access to the entire flash device 

• - We are trusting the phone's kernel 
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Exploitation 



<3>[ 684.803710] init: untracked pid 3882 exited 

<3>[ 684.803833] init: untracked pid 3883 exited 

<3>[ 684.803955] init: untracked pid 3884 exited 

<3>[ 684.804199] init: untracked pid 3885 exited 

<3>[ 684.804321] init: untracked pid 630 exited 

<6>[ 723.455749] [HTC_BATT]RSNSP=67, RARC=6,Vo1=3781mV,Current=299mA,Temp=288c(l/10) 

<6>[ 723.455963] batt: ds2784_notify : 1 6 at 719276978798 (1980-01-06 00:14:06.669006333 UTC) 

<6>[ 723.462738] batt: batt:power_supp1y_changed : battery at 719283875771 (1980-01-06 00:14:06.675750718 UTC) 

<6>[ 783.453399] [HTC_BATT]RSNSP=67, RARC=6,Vo1=3781mV,Current=301mA,Temp=288c(l/10) 

<6>[ 843.457244] [HTC_BATT]RSNSP=67, RARC=7,Vo1=3781mV,Current=301mA,Temp=288c(l/10) 

<6>[ 843.457458] batt: ds2784_notify : 1 7 at 839278474159 (1980-01-06 00:16:06.670501694 UTC) 

<6>[ 843.464019] batt: batt:power_supp1y_changed : battery at 839285035439 (1980-01-06 00:16:06.677062974 UTC) 

<6>[ 903.451873] [HTC_BATT]RSNSP=67, RARC=7,Vo1=3781mV,Current=301mA,Temp=290c(l/10) 

# cat /pro ope c/mtd 

mtdO: OOOaOOOO 00020000 "misc" 

mtdl: 00500000 00020000 "recovery" 

mtd2: 00280000 00020000 "boot" 

mtd3: OfaOOOOO 00020000 "system" 

mtd4: 02800000 00020000 "cache" 

mtd5: 093a0000 00020000 "userdata" 
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Get I/O Channel 



rootfs / rootfs ro 

tmpfs /dev tmpfs rw,mode=755 

devpts /dev/pts devpts rw,mode=600 

proc /proc proc rw 

sysfs /sys sysfs rw 

tmpfs /sq"lite_stmt_journa1s tmpfs rw, size=4096k 

none /dev/cpuctl cgroup rw,cpu 

/dev/block/mtdblock3 /system yaffs2 ro 

/dev/b"lock/mtdblock5 /data yaffs2 rw,nosuid, nodev 

/dev/block/mtdblock4 /cache yaffs2 rw, nosuid, nodev 

tmpfs /app-cache tmpfs rw,size=8192k 

/dev/b"lock//vold/179:l /sdcard vfat 

rw , di rsync , nosui d , nodev , noexec , ui d=1000 , gi d=1015 , f mask=0702 , dmask=0702 , al "I oi 

l,shortname=mixed,utf8,errors=remount-ro 

# mount -o exec, remount /dev/block//vold/179: 1 /sdcard 

# cd /s sdcaard rd 

# chmod 755 nanddump 

# Is -1 

d---rwxr-x system sdcard_rw 1980-01-06 10:01 LOST.DIR 
r-xr-x system sdcard_rw 713750 2011-12-16 20:47 nanddump 



;=0020, codepage=cp437,iochar£ 
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Acquire 



-1 /dev/md td/ 



cr--rw radio diag 

# ./nanddump — bb=dumpbad - 
ECC failed: 



ECC ( 



icted: 



Number of bad blocks: 
Number of bbt blocks: 
Block size 131072, page £ 
Dumping data sta 



90 



90 



11 1980-01-06 10:02 mtd5ro 

10 1980-01-06 10:02 mtd5 

9 1980-01-06 10:02 mtd4ro 

8 1980-01-06 10:02 mtd4 

7 1980-01-06 10:02 mtd3ro 

6 1980-01-06 10:02 mtd3 

5 1980-01-06 10:02 mtd2ro 

4 1980-01-06 10:02 mtd2 

3 1980-01-06 10:02 mtdlro 

2 1980-01-06 10:02 mtdl 

1 1980-01-06 10:02 mtdOro 

1980-01-06 10:02 mtdO 

f ./mtdO. nanddump /dev/mtd/mtdO 




: 0x00000000 and ending at OxOOOaOOOO. . . 
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Dismantle phone 
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Identify JTAG points 




Source: RIFF Box JTAG Manager 



Connect Jig & Power 
cables 
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JTAG acquisition: Connect to JTAG 
adapter 
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Dump flash 



i °i 



JTAG Manager for RIFF Box. Version: 136 



O Resurrection ?? JTAG Read/V.Vite DCC Re?7-'..V"!;e j useful Plug,ns - Box Service'' 




1 


1 Address; ; 00100000 


Length: '00000038 




1 1 


I Source File: ... H 


L ,i 



~a-ge: R±;e: i. I-:- 
[ C^ Ex ecute Script 
. -?., Analyze JTAG Chain 
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Connect a Get ID 



JTAG TCK Speed: 


2 MHz 




■" 






*# Resurrector Settings 


ASUS 


*l 




1 Asus P526 


♦ 1 


R Custom Target Settings 




Target (Core): 


ARM926 


Reset Method: 


JTAG I/O Voltage: 






TAP# {Multichain position): 




•J 
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JTAG acquisition 

• ! Grey market hardware/software 

• ! Finicky 

• + Complete acquisition 

• + No kernel involvement 
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Chip off acquisition 

Dismantle phone++ 

Identify flash 

Determine solder melting point 

- Lead free testing kit 
Remove flash 

- Kapton tape thermocouples to monitor temperature 

- Controlled heat to chip (BGA IR Rework or Hot Air) 
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KA100O015E-BJTT 



datasheet 



Rev. 1.0 

MCP Memory 



137-Ball Fine pitch Ball Grid Array Package (measured in millimeters) 



#A1 INDEX MARK 




[ TOP VIEW ) 




BOTTOM VIEW 



Source: Samsung KA100O015E-BJT rev 1.0 Datasheet 



post flash chip 
removal 
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Chip off acquisition 



Cleaning of chip 

- Removal of excess solder 

- Removal of BGA underfill 

- Clean with Isopropyl alcohol 

Re-balling 

- Kapton tape chip to underside of stencil 

- Apply solder paste and squeegee 

- Melt solder with hot air 
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re-balling stencil 
and re-balled chip 
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Chip off acquisition 

Acquire chip footprint specific adapter 

- Wide variety in chip sizes 

Acquire chip contents 

- Universal programmer 

- Build your own 
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Chip off acquisition 



? Heat effects on flash content 
? Moisture + heat effects 
! Finicky++ 
! Expensive tools 
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Analysis of Flash Volume 



Interpretation methodology 

1. Determine flash image format 

2. Identify partition layout 

3. Yaffs2: Identify tags layout 

- Byte plots [1] as a perception enhancing tool 

4. Interpret YAFFS Structures 



[1] Conti et al (2010) Automated mapping of large binary objects using primitive 
fragment type classification 



© 2013 Schatz Forensic 



Byteplot tool 

Each byte in source image = one greyscale value 

[1] 

Organised with: 

- visual cues seperating spare from user data area 

- multiple columns (populate down then right) 



[1] Conti et al (2010) Automated mapping of large binary objects using primitive 
fragment type classification 
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Determine flash image format: 
inline spare vs End spare 





si 



^lx 




acquisition w/ 
spare at end 



JTAG image normalised 
to inline spare 
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Clear delineation between spare and 

user data 




Clear delineation between spare and 

user data 




Identification of the partition layout 




Kernel dmesg flash partitioning is the 
most straightforward 

<6>[ 10.202087] msm_nand: allocated dma buffer at ffaOlOOO, dma_addr 

3blac000 

<6>[ 10.208343] msm_nand: read CFGO = aa5400c0 CFGl = 6746e 

<6>[ 10.213317] msm_nand: CFGO cw/page=3 ud_sz=512 ecc_sz=10 spare_sz=4 

<6>[ 10.219757] msm_nand: NAND_READ_ID = 5500bcec 

<6>[ 10.224060] msn_nand: nandid 5500bcec status c03120 

<6>[ 10.228881] msm_nand: manuf Samsung (Oxec) device Oxbc blocksz 20000 

pagesz 800 size 20000000 

<6>[ 10.237274] msm_nand: save CFGO = e85408c0 CFGl = 4745e 

<6>[ 10.242584] msm_nand: CFGO: cw/page=3 ud_sz=516 ecc_sz=10 spare_sz=0 

num_add r_cycl es=5 

<6>[ 10.250457] msm_nand: DEV_CMDl: f00f3000 

10.254455] msm_nand: NAND_EBI2_ECC_BUF_CFG: Iff 

10.258911] Creating 6 MTD partitions on "msm_nand" : 



<6>[ 
<5>[ 
<5>[ 
<5>[ 
<5>[ 
<5>[ 
<5>[ 
<5>[ 



10 . 263946] OxOOOOlff 60000-0x000020000000 

10.270080] 0x000004240000-0x000004740000 

10.279846] 0x000004740000-0x0000049c0000 

10.283508] 0x0000049c0000-0x0000143c0000 

10. 556365] 0x0000143c0000-0x000016bc0000 

10.600402] 0x000016bc0000-0x00001ff 60000 



rmsc 

"recovery" 
"boot" 
"system" 
"cache" 
"userdata" 



/proc/mtd doesn't give offset (and the 
partitions may be out of order) 



# cat 


/pro ope 


c/mtd 




dev: 


size 


erasesize 


name 


mtdO: 


OOOaOOOO 


00020000 


"misc" 


mtdl: 


00500000 


00020000 


"recovery" 


mtd2: 


00280000 


00020000 


"boot" 


mtd3: 


OfaOOOOO 


00020000 


"system" 


mtd4: 


02800000 


00020000 


"cache" 


mtd5: 


093a0000 


00020000 


"userdata" 



YAFFS2 Volumes are distinguished by Object 
Header Striations 




YAFFS2 File (Object) metadata is stored 
in the user data area 




struct ObjectHeader { 

int type; 

Uint parentObjectID; 

Short sum NoLongerUsed; 

char[256] name;//nullterminated 

short reserved; 

uint long yst_mode; 

uintuid; 

int yst_gid; 
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YAFFS2 File (Object) metadata is stored 
in the user data area 




* Carving criteria identified by Pooters (2011) Yaffs2 Object Headers DFRWS 

© 2013 Schatz Forensic 



Object Header Striations Interpreted 




Object Typ 
Metadata 
Name (nu 
termination is L 




== OxFF (white) 
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Theory indicates that Packed Tags and 
ECC should be in spare 




'I'M^'iM}:^ 'uU 
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Packed tag location and layout are 
currently a source of conflicting results 



bytes 



24 



Table 12 YAFFS 2 Spare data structure 



YAFFS 

consists of; 



Chunk ID (20) (if is a header (directory entry) if > 
1 is data and position) 



ObjeetlD (0 if unused) 



nBytcs, number of bytes used in the chunk, 
Ox 00 08 = 0x0800 = 2048 - fall 



Sequence number 



ECC for tags 



ECC for data 



block status (damaged) 



data status (dirty) 





00 


01 


02 | 03 | 04 | 05 


06 | 07 | 08 | 09 


oa|ob|oc|od 


0E 


OF 


00 






Block ID 


Object ID 


Parent Object ID 


File 


10 


-size 


ECC 


















20 




i i i rr 






















Obj 






■ 


ect Type 


| Extended Tag Flag 



Figure 6, 'Extended Tag" structure of Di'oicl flash memory 



Source: Quick & Alzabbi (2011) Forensic analysis of the Android File System YAFFS2 
Source: Bang et al (2011) DFRWS 2011 Forensic Challenge 



YAFFS2 Basics: Simple file write 




Object Header 

ChunklD = 
File Name = "a" 
Sequence = 0x1001 
Size = 



Data block 1 

ChunklD = l 
Address = 0x0 
Sequence = 0x1001 



Data block 2 

ChunklD = 2 
Address = 2048 
Sequence = 0x1001 



Object Header 



ChunklD = 



File Name = "a" 



Sequence = 0x1001 



Size = 4096 
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The ChunkID is distinguishable in 
sequentially written large files 




The Sequence Number is Constant 
within the Erase Block 




Source: 
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A spare of 56 doesn't seem consistent 
with our current physical flash theory 

# ./nanddump --bb=dumpbad -o -f ./mtdO.nanddump 
/dev/mtd/mtdO 

ECC failed: 

ECC corrected: 

Number of bad blocks: 

Number of bbt blocks: 

Block size 131072, page size 2048, OOB size 56 

Dumping data starting at 0x00000000 and ending at 
OxOOOaOOOO. . . 




Why is the Object Header over filling 
the User Data area ? 




Chip off dump ofkklbOOOlSM-AJTT 



*tf\ CI 



And what are these vertical lines? 
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Is that EEC (note the high entropy) in 
the user data area? 
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The Flash Controller is potentially the 

problem 



















Linux Kernel 
















Flash controller 

virtualises the view 

of the page 



















































Flash 
Controller 



MMCCard 
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Why is the Object Header over filling 
the User Data area 





■• — " : .'.. ■ i:^S^^^^^^^ 




Kii^ I ■■■' 
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Why is the Object Header over filling 
the User Data area 




i 



S3 
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Column relocation 




■ • 
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Column relocation 




: 
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Column relocation 




: 
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Column relocation 
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Column relocation 




.'r-f '.'■"/ 
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Analysis of the 
YAFFS2 Filesystem 



Kfl 



Current freely available YAFFS2 

implementations don't generally work 

with physical images 

• Variable results with even pseudo physical 
images 

• No support for prior object versions 
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YAFFS2 Sparse file creation 




Object Header 

ChunklD = 
Sequence = 0x1001 
File Name = "a" 
Size = 




Object Header 

ChunklD = 
Sequence = 0x1001 
File Name = "a" 
Size = *sparse* 





iu 








Object Header 






Object Header 


ChunklD = 


ChunklD = 


Sequence = 0x1001 


Sequence = 0x1001 


File Name = "a" 


File Name = "a" 


Size = 0x1000 


Size = 0x1000 
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YAFFS2 Block Replace 



t4\ CI 




Object Header 



ChunklD = 



Sequence = 0x1001 



File Name : 



Size = 



Data block 2 



ChunklD = l 



Address = 0x0 



Sequence = 0x1001 



Expired 





Data block 2 


ChunklD=l 


Address = 0x0 


Sequence = 0x1002 


New data block 





Object Header 



ChunklD = 



Sequence = 0x1002 



File Name = 



Size = 4096 
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YAFFS2 Version Recovery 




Object Header 



ChunklD = 



Sequence = 0x1001 



File Name : 



Size = 



Data block 2 



ChunklD = l 



Address = 0x0 



Sequence = 0x1001 



Expired 





Data block 2 


ChunklD=l 


Address = 0x0 


Sequence = 0x1002 


New data block 





sequence 

0x1002 and 

lower 



Object Header 



ChunklD = 



Sequence = 0x1002 



File Name = "a" 



Size = 4096 
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YAFFS2 Version Recovery 




Object Header 



ChunklD = 



Sequence = 0x1001 



File Name : 



Size = 



Data block 2 



ChunklD = l 



Address = 0x0 



Sequence = 0x1001 



Expired 



Data block 2 


ChunklD=l 


Address = 0x0 


Sequence = 0x1002 


New data block 



Object Header 



ChunklD = 



Sequence = 0x1002 



File Name = "a" 



Size = 4096 
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Acquisition methodology 



Acquisition Methodology 

JTAG or RAM Bootloader Acquisition 

- Recover PIN 
Live acquisition 

- Use PIN if necessary 

- Disable radios 

- Enable ADB 

- Exploit (you have validated it yes?) 

- Collect dmesg, /proc/mtd 

- Pseudo physical acquisition 

- Logical acquisition (for validation) 
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Conclusions 



Contributions 

Byte plots assist in identifying structure in raw 
byte sequences 

Inconsistencies in prior research resolved in part 

Visual artefacts corresponding to structural 
elements identified 

A general acquisition methodology for JTAG 
based analysis proposed 
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Future Work 

Partitioning 

Automated normalisation 
Effects of heat on NAND integrity 
JTAG for Volatile Memory Analysis ? 

eMMC 
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